After completing this lesson, you’ll be able to:
The FME log file is your best friend for debugging. It tells you how long a translation took, where the time went, and how well FME used the available system resources.
The first thing to notice is that each line of the log is (in most cases) a separate message, for example:
Creating writer for format: Esri Shapefile
However, sometimes the message spans several lines, such as:
Feature Caching is ON
The workspace may run slower because features are being recorded on all output ports.
Stop At Breakpoints is ON
The workspace may run slower, even when no breakpoints are present. In particular, Bulk Mode is not supported with this enabled.There are several options to adjust what appears in the log file. To access these, select Tools > FME Options > Translation:
The critical setting is Log Timestamp Information. This option turns on many optional fields in the log messages. These are:
For example:
2025-04-01 12:13:55| 0.8| 0.0|INFORM|Closing native MapInfo reader
You can use these timestamps to identify slow sections of your workspace.
The log file always contains timestamps, regardless of this setting.
A common requirement is to filter log messages so only messages of a specific type are displayed. For example, turning off INFORM and STAT messages can make spotting ERRORs and WARNs easier.
You can filter the log using the buttons at the top of the Translation Log window:
These buttons can toggle messages on and off in the log window only.
The Log Debug option (under FME Options) allows you to turn on debug messages in the log. These are extra log messages that do not appear by default. Debug logging records additional translation information to the job log. “Debug mode” is best used when an error has already occurred and you seek further information. For example, in the event of a web and database failure, “debug mode” will often record more detailed information about the request, response, and transaction to the job log.
You should turn this off when you are not using it, as it can dramaticly increase the size of your log files. This setting can become an issue on FME Flow in particular, where users might be running a workspace very often.
Debug messages can help during debugging but are less useful in general FME use. Many messages (labeled "BADNEWS") are alarming “errors” that FME has trapped and kept to itself (like an end-of-file message). For this reason, you should not turn this option on permanently.
Also, note that the Log Debug setting persists in the workspace. If you turn that setting on and pass the workspace to another user, it retains the setting and shows debug messages when other users run it!
If the log window text is too small or not stylish enough, use Tools > FME Options > Appearance > Log Font to change the font size and style.
Having determined that the encoding issue appears to be happening when FME writes the data, Frank decides to dig into the log to see if there are any errors or warnings that indicate what might be happening.
He opens the starting workspace (C:\FMEData\Workspaces\UseDataIntegrationBestPractices\customize-and-filter-the-log.fmw) using FME Workbench (2025.0.1 or later) and runs it to generate caches.
He opens the Translation Log and checks for errors or warnings by examining the buttons at the top. There are zero errors but 17 warnings. He clicks the Warnings button to filter the log to only show warnings:
He can safely ignore the first two warning lines, as they are just about feature caching being turned on:
Feature Caching is ONThe workspace may run slower because features are being output and recorded on all output ports regardless of whether or not there is a connection.
But the lines after that are interesting. There are many that come from the CSV writer and report that FME can't convert the string (text) for some features from UTF-8 encoding to IBM437 encoding. Here's one example line:
CSV writer: The string 'Marisa Marmol,麥毅倫,1001,Lagoon Drive ,Vancouver,British Columbia,V6G4W5,Canada,Safe Software,20250603135542.7336085' could not be converted from 'UTF-8' to 'IBM437'. Changing your writer encoding to UTF-8 will avoid a potential loss of data
These messages further confirm there is a writing encoding issue. They also contain a clue: the writer is configured to write to IBM437 encoding, also known as code page 437. This encoding does not support Chinese characters.
Fun fact: the code pages, or encoding definitions, used by IBM are so named because they originally refered to pages in the IBM standard character set manual! With many iterations, they eventually broke that connection, but the terminology remained.
So, now Frank suspects the writer might be set to use the wrong encoding.
Frank expands the CSV writer in the Navigator and finds the Parameters > Encoding parameter. Sure enough, it's set to IBM437:
He double-clicks it and changes it to Unicode 8-bit (utf-8), a standard encoding that does support Chinese characters:
Frank reruns his workspace to write the data using the new encoding.
First, he inspects it by clicking the writer feature type and using Inspect Written Data:
Then, he double-checks by opening the data in the destination software, in this case, Microsoft Excel:
The encoding is fixed and the Chinese characters appear correctly! Problem solved.
Encoding is a good example here, but it's also an example of where you should check that your computer can view such data. If your computer is in the wrong locale, it might be impossible.
